Method and system for optimizing network performances

ABSTRACT

A method for optimizing network performances, wherein the network includes one or more network nodes ( 1 ), performance parameters of the network nodes ( 1 ) being controlled by element of dedicated optimization modules ( 3 ), wherein each optimization module ( 3 ) monitors at least one performance parameter of the network node ( 1 ) to which the optimization module ( 3 ) is associated and generates a change request for the current value of the performance parameter on the basis of preset rules, is characterized in that the change requests generated by different optimization modules ( 3 ) of the network node ( 1 ) are forwarded to a shared controlling element ( 2 ), wherein the shared controlling element ( 2 ) enforces a coordination of the received change requests on the basis of a configurable algorithm. Furthermore, a corresponding system is disclosed.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to a method for optimizing networkperformances, wherein the network comprises one or more network nodes,performance parameters of said network nodes being controlled by meansof dedicated optimization modules, wherein each optimization modulemonitors at least one performance parameter of the network node to whichsaid optimization module is associated and generates a change requestfor the current value of said performance parameter on the basis ofpreset rules.

Furthermore, the present invention relates to a system for optimizingnetwork performances, the system comprising dedicated optimizationmodules for controlling performance parameters of network nodes of thenetwork, wherein each optimization module is configured to monitor atleast one performance parameter of the network node to which saidoptimization module is associated and to generate change requests forthe current value of said performance parameter on the basis of presetrules.

2. Description of the Related Art

The maintenance of a network involves a continuous process, where someperformance data is analyzed and some configuration parameters arechanged to maintain or optimize network performances. This is normallycalled “optimization process” of a network.

An optimization process in current networks is normally veryspecialized, i.e. there is a specific function module which is referredto as optimization module and which is delegated to optimize a specificperformance parameter. From a black-box perspective, an optimizationmodule reads the performance data and generates the new configurationfor the network. The decision is based on goals enforced by the networkadministrator and by some additional constraints (“contour conditions”).Such optimization process is illustrated in FIG. 1.

As an example of a performance parameter to be monitored on a networknode one can think of the average load or the average number of servicerequests rejected (e.g. telephone calls or network connections). In thelatter case the number of service requests rejected would becontinuously monitored and if the number exceeds certain thresholds(e.g. more than 10 requests rejected per hour), the optimization processwould be started. In the case of a wireless network, in order toregulate the distribution of load between base stations, the power ofthe “pilot channel” of the base stations is normally tuned in: thehigher the power, the bigger the area covered and the higher the averageload received by the base station. Therefore, if a base station has toomuch load, with respect to predefined goal values, the optimizationprocess would try to decrease the power of the pilot channel providedthat some contour conditions are respected (e.g. a condition may requirefull coverage area).

Currently, in operative networks optimization processes as describedabove are executed on a central management station, which sends newconfiguration parameters to the managed network nodes. Moreover,normally the optimization process is performed manually by a person,e.g. the network administrator, who sends the configuration values. Asfor the example described above, it is likely that the values for thepowers of the pilot channels of the base stations are configuredmanually, only after some alarms are reported to the administrator. Forinstance, in case certain preset thresholds on the load are overcome, analarm is reported to a management station and the administrator is incharge to define a new value for the power of the pilot channel. Thismethod, which is illustrated together with the related data flow in FIG.2, is clearly time-consuming, error-prone and not efficient.

However, some degree of automation is sometimes adopted through the useof some scripts, which is also illustrated in FIG. 2. For example, ascript can automatically change the value of a performance parameter ofa network node, e.g. the power of the pilot channel of a base station ofcellular communication network. Anyway, this is normally applied only onlimited cases, because the execution of these scripts requires a properdesign and dedicated computational resources. Moreover, since they areexecuted on a single central management station, this automated methoddoes not scale for large networks.

Recently emerging network architectures will try to use self-organizingprinciples as much as possible: the optimization processes will beautomated and delegated to the managed network nodes as much as possibleand different modules (e.g. programs implementing specific optimizingalgorithms) will be executed locally to change many parameters. It isexpected that each module will be designed for a specific function andwill control a specific domain of the configuration parameters. Nodescan collaborate with each other, by exchanging information and/orcommands. The advantages of such architecture are scalability, promptintervention and reduced need of manual intervention. An example of suchself-optimizing network architecture is shown in FIG. 3.

One of the problems of this approach is the coordination of thedifferent optimization processes within the same network node andbetween different nodes. The problem is that the self-optimizing modulesare designed and implemented independently. As a consequence, eachmodule is not aware of the presence or the functions of the other one.The reasons for this are both technical and practical. Technically thedesign of a standalone optimizing algorithm and module is much easierthan a combined problem. Practically each module is designed as answerto different problems and therefore the different modules are puttogether in the late integration stage of a product development, or evenworse during the deployment of the network.

An exemplary use case for self-optimizing nodes in the evolved UTRAN isthe adaptation of the cell coverage of the cells, depending on theworking conditions of the neighboring cells. More in detail, if a cellis not working or is switched off for energy saving purposes (e.g. overnight), its neighboring cells should increase their own coverage areasto maintain full coverage over the previous area. The coverage area isadapted by changing the power of the pilot channel of the cell. Theproblem is that the power of the pilot channel is also controlled by aload balancing mechanism. The concurrent access of two self-optimizingmechanisms to the same performance parameter can lead to unwantedeffects, like a high frequency of changes of a parameter (e.g. power ofthe pilot channel changing several timers per minute) or oscillations ofa parameter (e.g. a power of the pilot channel oscillating between twohigh and low values).

To solve these problems, it has already been proposed to implementadditional logic inside each module to coordinate the interactions withother modules. The drawback of such an approach is however that itresults in several points of attachment for the input of operator'spolicies and that it certainly requires additional complexity and addsadditional costs. Moreover, this approach is not general for anyadditional module: when a new optimization module is introduced in thenetwork entity and it interferes with an existing module, the existingmodule must be implemented again to take in account the interferences ofthe new module. At the end one would have “heavy modules” and eventuallythe costs for the required synchronization logic on each module maycompensate the benefits of the automation introduced.

To summarize, the new architectures with local automated optimizationprocesses will have the problem of concurrent configuration changes withrespect to three aspects: First, concurrent change requests on the sameconfiguration parameters coming from different modules. For example, aload balancing module and a cell outage module can concurrently changethe power of the pilot channel. The problem is evident when theconcurrent modules want to enforce opposite values (e.g. one modulesincreases and the other decreases the value). Secondly, concurrentchange requests coming from different nodes, and, thirdly, repeatedchange requests on the same configuration parameter. For example thechange requests could occur too often and some requests should befiltered. This effect is clearly more evident when different modules areinvolved. The side effects of these concurrent changes are unwantedconfigurations (i.e. bad values) or unwanted dynamics (e.g. too frequentchanges) of the configuration of the node.

SUMMARY OF THE INVENTION

It is therefore an object of the present invention to improve andfurther develop a method and a system of the initially described typefor optimizing network performances in such a way that by employingmechanisms that are readily to implement and that do not requireextensive additional complexity, negative effects on network performancecaused by concurrent conflicting change requests of differentoptimization modules of a network node are widely reduced.

In accordance with the invention, the aforementioned object isaccomplished by a method where change requests generated by differentoptimization modules of said network node are forwarded to a sharedcontrolling element, wherein said shared controlling element enforces acoordination of the received change requests on the basis of aconfigurable algorithm.

Furthermore, the aforementioned object is accomplished by a system foroptimizing network performances is characterized in that the systemfurther comprises a shared controlling element to which said changerequests generated by different optimization modules of said networknode are forwarded, wherein said shared controlling element isconfigured to enforce a coordination of the received change requests onthe basis of a configurable algorithm.

According to the invention, it has first been recognized that animplementation of additional logic inside each optimization module forresolving conflicting change requests proves to be disadvantageous invarious aspects. Furthermore, it has been recognized that a veryefficient coordination process becomes possible by implementing anadditional entity which operates separate from the single optimizationmodules of the network node. This additional entity is implemented as ashared controlling element to which change requests generated bydifferent optimization modules of the network node are forwarded.Insofar, the controlling element constitutes a central entity from theviewpoint of the optimization modules. Upon receipt of change requestfrom the optimization modules, the coordination module enforces acoordination of the concurrent change requests. The coordination processis based on a configurable algorithm which may easily be enforced bye.g. a network administrator. Furthermore, as the controlling element isshared among different optimization modules it allows for fullmodularization of self-optimization processes.

According to a preferred embodiment the controlling element isconfigured as to resolve conflicts of change requests receivedconcurrently from different optimization modules of a network node. Tothis end, optimization goals may be provided, e.g. by the networkadministrator, that define a trade-off between different optimizationmodules. Such optimization goals may be passed to the controllingelement and may be taken into account in the coordination process.

More specifically, according to the specific algorithm employed in thecontext of the coordination process, the controlling element maygenerate the average of change requests received from the optimizationmodules. In a preferred embodiment, a weighted average is calculated. Byassociating different weights to each optimization module, cross-modulegoals, i.e. conflicting goals between the single optimization modules,can be taken into account. For example, concurrent change requests forthe performance parameter the power of a pilot channel (e.g. of a basestation) may be coordinated by giving a high weight to an optimizationmodule which is in charge of an error control and giving a low weight tothe optimization module which is in charge of load balancing issues andaveraging the values given by the optimization modules with theseweights.

Alternatively or additionally, cost functions for the performanceparameter under control may be passed to the controlling element and maybe considered in the coordination process. The term “cost function” isto be understood in a broad sense and gives an evaluation of thenegative impacts on the network performance caused by the setting of aperformance parameter in the resources of a network node. Such negativeaspects may include, but are not limited to, service interruptionsand/or consumption of CPU power. By taking into account such costfunctions in the context of the coordination process the case may arisethat a decision is made not to change a performance parameter (althoughthis might be reasonable when exclusively considering optimizationgoals) as the negative impacts of such performance parameter change mayovercompensate the benefits resulting from a change of the performanceparameter.

In a still further preferred embodiment the controlling element may beconfigured as to function as a filter, i.e. change requests receivedfrom one or more of the optimization modules may be blocked by thecontrolling element. Advantageously, the blocking may be carried outselectively for single optimization modules which may be specified by anetwork administrator. For instance, in case the network operatordefines policies according to which the avoidance of rejections ofservice requests is granted highest priority, only change requests ofthe optimization module responsible for monitoring such service requestrejections may be taken into account by the coordination module, whereaschange requests from all other optimization modules of the respectivenetwork node may be blocked. Furthermore, the controlling element may beconfigured as to selectively overwrite the values requested by theoptimization modules.

It is to be understood that the blocking functionality may be combinedwith the generation of (weighted) averages of change requests of theoptimization modules. For example, it may be provided that oneoptimization module is blocked whereas an average value is generated forthe other modules. From time to time, e.g. in time intervals ofconfigurable length, the current change request of the blockedoptimization module may be considered for the average generation. Bythis means it can be ensured that the value of the performance parameterunder control does not run out of range as regards the optimizationissues for which the blocked optimization module is responsible.

After having performed the coordination of the change requests receivedfrom the optimization modules of the network node under control, it maybe provided that the controlling element outputs a new configurationvalue for the performance parameter under control. Advantageously, thecontrolling element may be located, as regards the interaction flow,between the optimization modules and the access to the resources of thecontrolled network node. The term “resources” refers to the complete setof performance parameters of the network node. The output of thecontrolling element may then be used for performing an update of thevalue of the controlled performance parameter in the resources of thenetwork node.

It is to be noted that the functionality of the coordination module isnot limited to the creation of new values for certain performanceparameters. In addition, it may be provided that the coordination modulecan alter also the timing in which changes are enforced in the networknode's resources. For example, changes may be delayed in time in orderto avoid too frequent changes of a performance parameter. This is animportant application when the reconfiguration of a component takes acertain time, i.e. a few seconds or even a few minutes. In such a case,it is fundamental to limit the frequency of reconfigurations.

As concerns the interaction flow it may be provided that tuples areemployed, the tuples containing the performance parameter on the onehand and the configuration value of said performance parameter on theother hand. Insofar, a very simple and easy to handle interaction flowis realised. Regarding an easy handling of change requests it may beprovided that each change request is associated to the requestingentity. In particular, the association of a change request to therespective requesting entity may be performed by means of the name ofthe requesting entity. Furthermore, the employment of an identifierassociated to the requesting entity is possible.

Advantageously, a unique point of control of the coordination processperformed by the controlling element is provided. More specifically, thecoordination module may provide a specific input interface which allowse.g. a network administrator to configure the algorithm which isemployed by the coordination module for the coordination of receivedchange requests.

It is to be noted that any performance parameter of a network node maybe optimized as described above. In particular it is to be pointed outthat more than one performance parameter per network node may beoptimized. In such case a separate coordination element may be providedfor each performance parameter to be optimized. Collaboration betweenthe single coordination modules of a network node is possible. We namejust exemplarily the power of the pilot channel of a base station, thebandwidth of guard channels in the context of handovers and the receivedsignal threshold for network induced handovers as performance parameterswhich may be controlled and optimized.

There are several ways how to design and further develop the teaching ofthe present invention in an advantageous way. To this end, it is to bereferred to the following explanation of a preferred embodiment of theinvention by way of example, illustrated by the figures. In connectionwith the explanation of the preferred embodiment of the invention by theaid of the figures, generally preferred embodiments and furtherdevelopments of the teaching will we explained.

BRIEF DESCRIPTION OF THE DRAWING FIGURES

In the drawings:

FIG. 1 is a schematic illustration of the information flow in anoptimization process performed by means of an optimization moduleaccording to the state of the art,

FIG. 2 is a schematic illustration of an optimization process accordingto the state of the art which is carried out as a central process eithermanually or script-aided,

FIG. 3 shows an optimization process according to the state of the artin a self-optimizing network,

FIG. 4 shows schematically an embodiment of a system of optimizingnetwork performances according to the invention,

FIG. 5 is a diagram showing an example of concurrent change requestsform two different optimization modules for a specific performanceparameter without employing the method according to the invention, and

FIG. 6 is a diagram showing an example of concurrent change requestsform two different optimization modules for a specific performanceparameter under employment of an embodiment of the method according tothe invention.

DETAILED DESCRIPTION OF THE INVENTION

FIG. 1 is a schematic illustration showing the principles of anoptimization process of a network as it is performed in prior art. Anoptimization module is provided which continuously monitors a specificperformance parameter, e.g. a number of rejected services or the powerof the pilot channel of a base station. In the optimization process theoptimization module takes into account so called “contour conditions”which include certain constraints. Such contour condition might require,for instance, full coverage area. Furthermore, the optimization processis based on goals which are enforced e.g. by the network administrator.The optimization module outputs a new configuration value for theperformance parameter under control which, in general, is output in formof a change request.

FIG. 2 illustrates the architecture employed in operative networks forperforming optimization processes as described in connection withFIG. 1. The optimization modules are implemented on a central managementstation which reads performance data from the network nodes to bemonitored. This is indicated by the solid line arrows. Nowadays it isvery common that change requests are generated manually by the networkadministrator on the basis of the monitored results. It is also known inprior art to introduce some automation by employing scripts which canautomatically change the values of specific performance parameters.Configuration changes resulting from the optimization process aretransmitted from the central management station to the single nodes,which are indicated by the dotted line arrows.

FIG. 3 illustrates the situation for self-optimizing networks. In thisnetwork architecture the optimization process is widely automated anddelegated to the managed network nodes. As can be obtained from FIG. 3,different optimization modules (e.g. scripts) are executed locally onthe monitored network nodes (from which two are shown exemplarily) tochange a multitude of performance parameters. Each optimization moduleis designed for a specific function and controls a specific domain ofthe configuration parameters.

According to the example illustrated in FIG. 3 the network node on theright part is a base station, and the three self optimization modulesassociated to that base station are responsible for controlling thepower of the pilot channel of the base station. The small diagramstitled “example of configurations” show the change requests of thesingle optimization modules. Specifically, the power of the pilotchannel as a function of time is depicted. The change requests ofdifferent modules are forwarded to the resources of the monitorednetwork node which is again indicated by the dotted line arrows.According to the state of the art the change requests of differentmodules are treated individually. As a consequence, the power of thepilot channel suffers frequent changes, which is illustrated by thesmall diagram “example of configurations” associated to the resources.In this diagram the power of the pilot channel experiences strongoscillations over time.

FIG. 4 illustrates an embodiment of a system according to the presentinvention. For the sake clarity only one single network node 1 is shown.According to the invention a coordination module 2 is provided to whichchange requests generated by the optimization modules 3 of the networknode 1 are forwarded. The coordination module 2 comprises a specificinput interface 4 which allows for the configuration of the algorithmaccording to which the coordination module 2 handles the received changerequests. Insofar, e.g. the network operator 5 is given a unique pointof control of the coordination process. Via the input interface 4 it ispossible to define cost functions, to specify cross-modules goals and/orto enter filters in order to block certain change requests.

As already mentioned above, the coordination module 2 receives thechange request form the different optimization modules 3 and handlesthem according to the specified algorithm. For instance, thecoordination module 2 might resolve conflicts of concurrent changerequests or enforce cross-module optimization goals. As a result of theoptimization process the coordination module 2 outputs a newconfiguration value for the performance parameter under control. The newconfiguration value is provided via a specific output interface 6 of thecoordination module.

In the interaction flow, the coordination module 2 is located betweenthe optimization modules 3 and the access to the controlled resources 7of the managed network node 1. The new configuration value of theperformance parameter is forwarded to the resources 7 as indicated bythe dotted line arrow and the respective change will be executed.

Although in FIG. 4 the optimization modules 3 as well as thecoordination module 2 are depicted as being implemented locally, i.e. inthe managed network node 1, it is to be noted that these modules mayalso be implemented in a central management station. In this case,optimization algorithms would normally not be applied on localresources, but on remote resources located on the network node beingmonitored.

For the optimization modules 2 in the middle and on the right part,again, the diagrams titled “example of configurations” are depicted.Again, the power of the pilot channel is shown as a function of time.The functions are the same as the ones shown in FIG. 3. However, theresulting function, i.e. after performance of the coordination process,is much smoother than the resulting function of FIG. 3. As aconsequence, less changes of the performance parameter have to beexecuted which results in an optimized network performance as, inpractice, the execution of changes in the resources 7 of the networknode 1 are always accompanied by service interruptions or any otherdisadvantageous effects.

This aspect is further clarified by the diagrams shown in FIGS. 5 and 6.These diagrams illustrate change requests for the power of the pilotchannel over a time period of 20 seconds. The power on the ordinate isgiven in arbitrary units, e.g. in dBm or in watt. The solid barsrepresent change requests generated by the optimization module which isresponsible for the error control. On the other hand, the dotted barsrepresent change requests generated by an optimization module which isresponsible for load balancing issues.

FIG. 5 shows the situation without applying the present invention. Eachchange request generated by one of the two optimization modules isforwarded to the resources of the managed network node and respectivechanges of the performance parameter are executed.

FIG. 6 on the other hand shows the situation when applying theinvention, i.e. a coordination module is provided to which the changerequest of the two optimization modules are forwarded and which handlesconcurrent change requests according to a specified algorithm. Accordingto the embodiment shown in FIG. 6, a simple weighted average is used togenerate a new serious of values for the performance parameter undercontrol. Specially, different weights are associated the eachoptimization module according to their goals. In this example acoordination of the concurrent change requests for the power of thepilot channel is achieved by giving a high weight to the “error control”module and a low weight to the “load balancing” module. These values areaveraged. FIG. 6 shows the average value taken over all change requestswithin the illustrated 20 second time interval. As it can be seen, theoutput average value is closer to the value created by the “errorcontrol” module, because it has a higher weight.

FIG. 6 does not show the delay which is necessarily introduced by theaverage window. However, this is an important point, as the effect ofthe coordination module is not limited to the creation of new values. Infact, the coordination module can alter also the timing in which changesare enforced. For example, changes may be delayed in time in order toavoid too frequent changes of a performance parameter. This is animportant application when the reconfiguration of a component takes acertain time, i.e. a few seconds or even a few minutes. In such a case,it is fundamental to limit the frequency of reconfigurations.

Many modifications and other embodiments of the invention set forthherein will come to mind the one skilled in the art to which theinvention pertains having the benefit of the teachings presented in theforegoing description and the associated drawings. Therefore, it is tobe understood that the invention is not to be limited to the specificembodiments disclosed and that modifications and other embodiments areintended to be included within the scope of the appended claims.Although specific terms are employed herein, they are used in a genericand descriptive sense only and not for purposes of limitation.

The invention claimed is:
 1. A method for optimizing networkperformances, comprising: providing a network which comprises one ormore network nodes, each one of the network nodes including dedicatedoptimization modules and a controlling element, the controlling elementbeing shared by the dedicated optimization modules at the network node,the dedicated optimization modules and the controlling element eachbeing located locally at the network node, performance parameters ofsaid network nodes being controlled by the dedicated optimizationmodules; monitoring with each optimization module at least oneperformance parameter of the network node to which said optimizationmodule is associated and generating a change request for the currentvalue of said performance parameter on the basis of preset rules; andforwarding said change requests generated by different optimizationmodules of said network node to the controlling element at the networknode to which the optimization modules are associated, the controllingelement shared by the optimization modules enforcing a coordination ofthe received change requests on the basis of a configurable algorithm,wherein said controlling element resolves conflicts of change requestsreceived concurrently from different optimization modules of the networknode.
 2. The method according to claim 1, wherein optimization goalsthat define a trade-off between different optimization modules arepassed to said controlling element and are taken into account in acoordination process.
 3. The method according to claim 1, wherein saidcontrolling element, according to the configurable algorithm, generatesan average of the change requests received from the optimizationmodules.
 4. The method according to claim 3, wherein said algorithmincludes a routine for performing a weighting of the change requests,wherein the average is generated on a basis of the weighted changerequests.
 5. The method according to claim 1, wherein cost functions forthe performance parameter under control are passed to said controllingelement and are considered in a coordination process.
 6. The methodaccording to claim 1, wherein change requests received from one or moreof said optimization modules are selectively blocked by said controllingelement.
 7. The method according to claim 1, wherein said controllingelement outputs a new configuration value for the performance parameterunder control.
 8. The method according to claim 1, wherein saidcontrolling element is located between the optimization modules and theaccess to the resources of the controlled network node.
 9. The methodaccording to claim 1, wherein the output of said controlling element isused for performing an update of the value of the controlled performanceparameter in the resources of said network node.
 10. The methodaccording to claim 1, wherein said controlling element alters a timingin which changes of a performance parameter are enforced.
 11. The methodaccording to claim 1, wherein an interaction flow between involvedentities is performed by using tuples containing the performanceparameter and the configuration value of said performance parameter. 12.The method according to claim 1, wherein each change request isassociated to the requesting optimization module.
 13. The methodaccording to claim 12, wherein the association of a change request to arespective requesting entity is performed by the name of the requestingoptimization module and/or by means of an identifier associated to therequesting optimization module.
 14. The method according to claim 1,wherein the performance parameters being controlled include the power ofthe pilot channel of base stations, the bandwidth of guard channels inthe context of handovers and/or a received signal threshold for networkinduced handovers.
 15. A system for optimizing network performances, thesystem comprising: one or more network nodes each comprising dedicatedoptimization modules configured for controlling performance parametersof the network node, each optimization module being configured tomonitor at least one performance parameter of the network node to whichsaid optimization module is associated and to generate change requestsfor the current value of said performance parameter on the basis ofpreset rules; and a controlling element shared by the dedicatedoptimization modules at the network node to which said change requestsgenerated by different optimization modules of said network node areforwarded, the controlling element being configured to enforce acoordination of the received change requests on the basis of aconfigurable algorithm, wherein the dedicated optimization modules andthe controlling element are each locally located at the network node,and the system is configured to optimize network performance accordingto the following steps: providing the network which comprises the one ormore network nodes, each one of the network nodes including thededicated optimization modules and the controlling element, theperformance parameters of said network nodes being controlled by thededicated optimization modules; monitoring with each optimization modulethe at least one performance parameter of the network node to which saidoptimization module is associated and generating the change request forthe current value of said performance parameter on the basis of thepreset rules; and forwarding said change requests generated by differentoptimization modules of said network node to the controlling element atthe network node to which the optimization modules are associated, thecontrolling element shared by the optimization modules enforcing thecoordination of the received change requests on the basis of theconfigurable algorithm, and wherein said controlling element isconfigured to resolve conflicts of change requests received concurrentlyfrom different optimization modules of the network node.
 16. The systemaccording to claim 15, wherein said controlling element is configured asto receive cost functions for the performance parameter under controlwhich are considered in the coordination process.
 17. The systemaccording to claim 15, wherein said controlling element is enabled toselectively block change requests received from one or more of saidoptimization modules.
 18. The system according to claim 15, wherein saidcontrolling element is enabled to overwrite configuration valuesreceived from said optimization modules in the context of changerequests.
 19. The system according to claim 15, wherein said controllingelement outputs a new configuration value for the performance parameterunder control.
 20. The system according to claim 15, wherein saidcontrolling element is located between the optimization modules and anaccess to the resources of the controlled network node.
 21. The systemaccording to claim 15, wherein a unique point of control of acoordination process performed by said controlling element is provided.